Safe zero-cost coercions for Haskell

Generative type abstractions – present in Haskell, OCaml, and other languages – are useful concepts to help prevent programmer errors. They serve to create new types that are distinct at compile time but share a run-time representation with some base type. We present a new mechanism that allows for zero-cost conversions between generative type abstractions and their representations, even when such types are deeply nested. We prove type safety in the presence of these conversions and have implemented our work in GHC

Evidence Normalization in System FC (Invited Talk)

System FC is an explicitly typed language that serves as the target language for Haskell source programs. System FC is based on System F with the addition of erasable but explicit type equality proof witnesses. Equality proof witnesses are generated from type inference performed on source Haskell programs. Such witnesses may be very large objects, which causes performance degradation in later stages of compilation, and makes it hard to debug the results of type inference and subsequent program transformations. In this paper we present an equality proof simplification algorithm, implemented in GHC, which greatly reduces the size of the target System FC programs

Levity Polymorphism

Parametric polymorphism is one of the linchpins of modern typed programming, but it comes with a real performance penalty. We describe this penalty; offer a principled way to reason about it (kinds as calling conventions); and propose levity polymorphism. This new form of polymorphism allows abstractions over calling conventions; we detail and verify restrictions that are necessary in order to compile levity-polymorphic functions. Levity polymorphism has created new opportunities in Haskell, including the ability to generalize nearly half of the type classes in GHC\u27s standard library

Levity Polymorphism (extended version)

Parametric polymorphism is one of the lynchpins of modern typed programming. A function that can work seamlessly over a variety of types simplifies code, helps to avoid errors introduced through duplication, and and is easy to maintain. However, polymorphism comes at a very real cost, one that each language with support for polymorphism has paid in different ways. This paper describes this cost, proposes a theoretically simple way to reason about the cost—that kinds, not types, are calling conventions—and details one approach to dealing with polymorphism that works in the context of a language, Haskell, that prizes both efficiency and a principled type system. This approach, levity polymorphism, allows the user to abstract over calling conventions; we detail and verify restrictions that are necessary in order to compile levity-polymorphic functions. Lev- ity polymorphism has opened up surprising new opportunities for library design in Haskell

Levity Polymorphism (extended version)

Parametric polymorphism is one of the lynchpins of modern typed programming. A function that can work seamlessly over a variety of types simplifies code, helps to avoid errors introduced through duplication, and and is easy to maintain. However, polymorphism comes at a very real cost, one that each language with support for polymorphism has paid in different ways. This paper describes this cost, proposes a theoretically simple way to reason about the cost—that kinds, not types, are calling conventions—and details one approach to dealing with polymorphism that works in the context of a language, Haskell, that prizes both efficiency and a principled type system. This approach, levity polymorphism, allows the user to abstract over calling conventions; we detail and verify restrictions that are necessary in order to compile levity-polymorphic functions. Lev- ity polymorphism has opened up surprising new opportunities for library design in Haskell

Submission to the Commons Select Committee on Education

Computing is a rigorous, intellectually rich discipline alongside Maths, Science, or History. Like those subjects, Computing explores foundational principles and ideas, rather than training students in skills that date quickly. In an increasingly digital, knowledge-based age, Computing is fundamental both to full citizenship, and to our economic health as a nation. Yet, incredibly, Computing is virtually absent from UK schools. Instead, secondary schools in England currently teach ICT. The original concept behind ICT was to teach students how to use software to solve real-world problems. That would have been a tremendous achievement had it succeeded. However, what has actually happened in far too many schools is that ICT focuses solely upon IT literacy, and supporting teaching and learning in other curriculum contexts. ICT is not the discipline of understanding and knowledge of computers and the way they work.The creation of the EBac provides the perfect opportunity to send a clear signal to schools and pupils of the importance of Computing. Our key recommendation is that Computing (unlike ICT) should “count” towards the English Baccalaureate.On behalf of Computing at School:Dr. John WoollardProf. Simon Peyton-JonesDr. Bill Mitchel